冗長性の設計に関する推奨事項

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

関連ガイド:可用性ゾーンとリージョンを使用した高可用性マルチリージョン設計 |

このガイドでは、回復性を最適化するさまざまなワークロード レイヤーで重要なフロー全体に冗長性を追加するための推奨事項について説明します。 コンピューティング、データ、ネットワーク、その他のインフラストラクチャ層に適切なレベルの冗長性を適用することで、定義された信頼性ターゲットの要件を満たします。 この冗長性を適用して、構築する強力で信頼性の高い基盤をワークロードに提供します。 インフラストラクチャの冗長性なしでワークロードを構築すると、障害の可能性によりダウンタイムが長くなるリスク が高くなります。

定義

主要な設計戦略

信頼性のコンテキストでは、冗長性を使用して 1 つのリソースに影響する問題を含め、それらの問題がシステム全体の信頼性に影響しないようにします。 重要なフローと信頼性ターゲットについて特定した情報を使用して、各フローの冗長性に必要な情報に基づいた意思決定を行います。

たとえば、複数の Web サーバー ノードが一度に実行されている場合があります。 サポートするフローの重要度は、プール全体に影響を与える問題 (リージョンの停止など) がある場合に、すべてのレプリカにトラフィックを受け入れる準備ができているレプリカが必要になる場合があります。 または、大規模な問題はまれであり、レプリカのセット全体をデプロイするとコストがかかるため、問題を解決するまでフローが低下状態で動作するように、レプリカの数が限られている可能性があります。

パフォーマンス効率のコンテキストで冗長性を設計する場合は、複数の冗長ノードに負荷を分散して、各ノードが最適に実行されるようにします。 信頼性のコンテキストでは、1 つ以上のノードに影響を与える障害や誤動作を吸収するために、予備容量を組み込みます。 予備容量が、影響を受けるノードを回復するために必要な時間全体の障害を吸収できることを確認します。 この違いを念頭に置いて、両方の戦略を連携させる必要があります。 パフォーマンスのために 2 つのノードにトラフィックを分散し、両方とも 60% の使用率で実行され、1 つのノードが失敗した場合、残りのノードは 120% で動作できないため、過負荷になるリスクがあります。 負荷を別のノードに分散して、パフォーマンスと信頼性のターゲットが確実に維持されるようにします。

トレードオフ:

• ワークロードの冗長性の向上は、より多くのコストに相当します。 冗長性を追加することを慎重に検討し、特にオーバープロビジョニングを使用する場合は、コストを管理していることを確認するために、アーキテクチャを定期的に確認してください。 回復性戦略としてオーバープロビジョニングを使用する場合は、適切に定義された スケーリング戦略 とバランスを取り、コストの非効率性を最小限に抑えます。

• 高度な冗長性で構築すると、パフォーマンスのトレードオフが発生する可能性があります。 たとえば、可用性ゾーンまたはリージョンに分散するリソースは、Web サーバーやデータベース インスタンスなどの冗長リソース間の待機時間の長い接続経由でトラフィックを送信する必要があるため、パフォーマンスに影響を与える可能性があります。

• 同じワークロード内のフローによって、信頼性要件が異なる場合があります。 フロー固有の冗長性設計では、設計全体に複雑さが生じる可能性があります。

冗長アーキテクチャ設計

冗長アーキテクチャを設計する場合は、アクティブ/アクティブ/パッシブとアクティブ/パッシブの 2 つのアプローチを検討してください。 インフラストラクチャ コンポーネントがサポートするユーザー フローとシステム フローの重要度に応じて、アプローチを選択します。 信頼性の点では、複数リージョンのアクティブ/アクティブ設計は、可能な限り最高レベルの信頼性を実現するのに役立ちますが、アクティブ/パッシブ設計よりも大幅にコストがかかります。 適切な地理的リージョンを決定することが、次に重要な選択になります。 可用性ゾーンを使用して、1 つのリージョンに対してこれらの設計アプローチを使用することもできます。 詳細については、「 高可用性マルチリージョン設計の推奨事項」を参照してください。

デプロイ スタンプとスケールの単位

アクティブ/アクティブとアクティブ/パッシブのどちらのモデルでデプロイする場合でも、 デプロイ スタンプの設計パターン に従って、反復可能でスケーラブルな方法でワークロードをデプロイします。 デプロイ スタンプは、特定の顧客のサブセットにワークロードを配信するために必要なリソースのグループです。 たとえば、サブセットは、ワークロードと同じデータ プライバシー要件を持つ地域のサブセットまたはサブセットである場合があります。 各スタンプは、ワークロードを水平方向にスケーリングしたり、ブルーグリーンデプロイを実行したりするために複製できるスケール の単位 と考えてください。 デプロイ スタンプを使用してワークロードを設計し、回復性と管理の負担のためにアクティブ/アクティブまたはアクティブ/パッシブの実装を最適化します。 また、リージョン内の一時的なリソース容量の制約を克服するには、複数リージョンのスケールアウトの計画も重要です。

Azure リージョン内の可用性ゾーン

アクティブ/アクティブまたはアクティブ/パッシブのどちらの設計をデプロイする場合でも、アクティブリージョン内の 可用性ゾーン を利用して、回復性を完全に最適化します。 多くの Azure リージョンでは、複数の可用性ゾーンが提供されています。これは、リージョン内のデータ センターの個別のグループです。 Azure サービスに応じて、ワークロードの要素をゾーン間で冗長にデプロイするか、特定のゾーンに要素をピン留めすることで、可用性ゾーンを利用できます。 詳細については、「 可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。

インフラストラクチャ 層のガイダンス

コンピューティング リソース

• ワークロードに適した コンピューティング サービス を選択します。 設計するワークロードの種類によっては、いくつかのオプションが使用できる場合があります。 使用可能なサービスを調べ、特定のコンピューティング サービスで最適に動作するワークロードの種類を把握します。 たとえば、SAP ワークロードは通常、サービスとしてのインフラストラクチャ (IaaS) コンピューティング サービスに最適です。 コンテナー化されたアプリケーションの場合は、Azure Kubernetes Service (AKS) ソリューションとサービスとしてのプラットフォーム (PaaS) ソリューションのどちらを使用するかを決定するために制御する必要がある特定の機能を決定します。 クラウド プラットフォームは、PaaS サービスを完全に管理します。

• 要件で許可されている場合は、PaaS コンピューティング オプションを使用します。 Azure は PaaS サービスを完全に管理するため、管理の負担が軽減され、文書化された冗長性が組み込まれています。

• 仮想マシン (VM) をデプロイする必要がある場合は、Azure Virtual Machine Scale Setsを使用します。 Virtual Machine Scale Setsを使用すると、コンピューティングを可用性ゾーン間で自動的に均等に分散させることができます。

• 要求を処理する個々のノードは、いつでも削除、障害、または置換される可能性があるため、コンピューティング レイヤーは任意の状態のクリーンします。

• 可能な場合はゾーン冗長サービスを使用して、運用上の負担を増やすことなく、より高い回復性を提供します。

• 自動スケーリング操作が開始される前であっても、冗長インスタンスの障害を軽減するために重要なリソースをオーバープロビジョニングするため、システムはコンポーネント障害の後も引き続き動作します。 冗長性設計にオーバープロビジョニングを組み込む場合に、障害の許容される影響を計算します。 冗長性の意思決定プロセスと同様に、信頼性目標と財務トレードオフの決定によって、過剰プロビジョニングで予備容量を追加する程度が決まります。 オーバープロビジョニングとは、特に スケールアウトを指します。つまり、1 つのインスタンスのコンピューティング機能を増やすのではなく、特定のコンピューティング リソースの種類のインスタンスを追加することを意味します。 たとえば、VM を下位レベルの SKU から上位レベルの SKU に変更する場合です。

• ソリューションを実装する予定の各可用性ゾーンまたはリージョンで、IaaS サービスを手動で、または自動化を使用してデプロイします。 一部の PaaS サービスには、可用性ゾーンとリージョン間で自動的にレプリケートされる組み込み機能があります。

データ リソース

• ワークロードの機能に同期データ レプリケーションと非同期データ レプリケーションが必要かどうかを判断します。 この決定に役立つ情報については、「 可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。

• データの増加率を検討します。 容量計画では、ソリューション内のデータ量が増えるにつれて信頼性要件が満たされるように、データの増加、データ保持、アーカイブを計画します。  

• 地理的にローカライズされたエラーの影響を最小限に抑えるために、サービスでサポートされている地理的にデータを分散します。

• 地理的リージョン間でデータをレプリケートして、リージョンの停止や致命的な障害に対する回復性を提供します。

• データベース インスタンスの障害後のフェールオーバーを自動化します。 複数の Azure PaaS データ サービスで自動フェールオーバーを構成できます。 Azure Cosmos DB などの複数リージョンの書き込みをサポートするデータ ストアでは、自動フェールオーバーは必要ありません。 詳細については、「 ディザスター リカバリー戦略を設計するための推奨事項」を参照してください。

• データに最適な データ ストア を使用します。 ポリグロットの永続化や、データ ストア テクノロジの組み合わせを使用するソリューションを採用します。 データには、永続化されたアプリケーション データ以上のものが含まれます。 アプリケーション ログ、イベント、メッセージ、およびキャッシュも含まれています。

• データ整合性の要件を考慮し、要件で許可されている場合 は最終的な整合性を 使用します。 データが分散されている場合は、適切な調整を使用して、強力な整合性の保証を適用します。 調整により、スループットが低下し、システムが密に結合され、システムが脆弱になる可能性があります。 たとえば、1 つの操作で 2 つのデータベースを更新する場合、1 つのトランザクション スコープに配置するのではなく、システムが最終的な整合性に対応できる方が適しています。

• 可用性のためにデータをパーティション分割します。 データベース パーティション分割により スケーラビリティが向上し、可用性も向上します。 1 つのシャードがダウンした場合でも、他のシャードに到達できます。 1 つのシャードで障害が発生すると、トランザクションの合計のサブセットのみが中断されます。

• シャーディングがオプションでない場合は、 コマンドとクエリの責任分離 (CQRS) パターン を使用して、読み取り/書き込みおよび読み取り専用のデータ モデルを分離できます。 より多くの回復性を提供するために、冗長な読み取り専用データベース インスタンスを追加します。  

• 使用するステートフル プラットフォーム サービスの組み込みのレプリケーションと冗長性の機能について理解します。 ステートフル データ サービスの特定の冗長性機能については、「 関連リンク」を参照してください。

ネットワーク

• 信頼性が高くスケーラブルなネットワーク トポロジを決定します。 ハブアンドスポーク モデルまたは Azure Virtual WAN モデルを使用して、クラウド インフラストラクチャを論理パターンで整理し、冗長性設計の構築とスケーリングを容易にします。

• リージョン内またはリージョン間で要求のバランスとリダイレクトを行う適切な ネットワーク サービス を選択します。 可能な場合は、グローバルまたはゾーン冗長の負荷分散サービスを使用して、信頼性の目標を満たします。

• スケールアウト要件など、計画的な使用を考慮するために、仮想ネットワークとサブネットに十分な IP アドレス空間が割り当てられていることを確認します。

• アプリケーションが、選択したアプリケーション ホスティング プラットフォームのポート制限内でスケーリングできることを確認します。 アプリケーションが複数の送信 TCP または UDP 接続を開始すると、使用可能なすべてのポートが使い果たされ、アプリケーションのパフォーマンスが低下する可能性があります。

• SKU を選択し、帯域幅と可用性の要件を満たすことができるネットワーク サービスを構成します。 VPN ゲートウェイのスループットは、SKU によって異なります。 ゾーン冗長のサポートは、一部のロード バランサー SKU でのみ使用できます。

• DNS を処理するための設計が回復性に重点を置いて構築され、冗長インフラストラクチャをサポートしていることを確認します。

Azure ファシリテーション

Azure プラットフォームは、ワークロードの回復性を最適化し、次の方法で冗長性を追加するのに役立ちます。

• 多くの PaaS およびサービスとしてのソフトウェア (SaaS) ソリューションで組み込みの冗長性を提供します。その一部は構成可能です。

• 可用性ゾーンとリージョン間の冗長性を使用して、リージョン内冗長性を設計して実装できるようにします。

• Azure Application Gateway、Azure Front Door、Azure Load Balancerなどのレプリカ対応負荷分散サービスを提供します。

• Azure SQL Database のアクティブ geo レプリケーションなどの簡単に実装された geo レプリケーション ソリューションを提供します。 Azure Cosmos DB を使用して 、グローバル分散 と透過的レプリケーションを実装します。 Azure Cosmos DB には、 競合する書き込みを処理するための 2 つのオプションが用意されています。 ワークロードに最適なオプションを選択します。

• 多くの PaaS データ サービスに対してポイントインタイム リストア機能を提供します。

• Azure NAT Gateway またはAzure Firewallを使用してポートの枯渇を軽減する。

DNS 固有の Azure ファシリテーション

• 内部の名前解決シナリオでは、ゾーンの冗長性と geo 冗長性が組み込まれている Azure DNS プライベート ゾーンを使用します。 詳細については、「 Azure DNS プライベート ゾーンの回復性」を参照してください。

• 外部の名前解決シナリオでは、ゾーンの冗長性と geo 冗長性が組み込まれている Azure DNS パブリック ゾーンを使用します。

• パブリックおよびプライベートの Azure DNS サービスは、ゾーン データがグローバルに利用できるため、リージョンの停止に対して回復性のあるグローバル サービスです。

• オンプレミス環境とクラウド環境の間のハイブリッド名前解決シナリオでは、Azure DNS Private Resolver を使用します。 ワークロードが可用性ゾーンをサポートするリージョンにある場合、このサービスはゾーンの冗長性をサポートします。 ゾーン全体の停止では、ゾーンの復旧中にアクションは必要ありません。 サービスは、正常なゾーンを利用するために自動的に自己修復と再調整を行います。 詳細については、「 Azure DNS Private Resolver の回復性」を参照してください。

• 単一障害点を排除し、リージョン間でより回復性の高いハイブリッド名前解決を実現するには、異なるリージョンに 2 つ以上の Azure DNS プライベート リゾルバーをデプロイします。 条件付き転送シナリオでは、DNS フェールオーバーは、リゾルバーをプライマリ DNS サーバーとして割り当てることによって実現されます。 別のリージョンの他のリゾルバーをセカンダリ DNS サーバーとして割り当てます。 詳細については、「 プライベート リゾルバーを使用して DNS フェールオーバーを設定する」を参照してください。

例

マルチリージョン冗長デプロイの例については、「 ベースライン高可用性ゾーン冗長 Web アプリケーション」を参照してください。

次の図は、別の例を示しています。

関連リンク

冗長性の詳細については、次のリソースを参照してください。

• Azure リージョン ガイド
• Azure Storage の冗長性
• ゾーン冗長ストレージ
• Azure SQL Database のアクティブ geo レプリケーション
• 2 つのマネージド インスタンス間のレプリケーションを構成する

信頼性チェックリスト

推奨事項の完全なセットを参照してください。